Which mechanism is suitable for which application? Some common use cases are considered in the table. The specific examples refer to a building control system.
Use case |
(A) Persistent variables |
(B) Retain variables |
(C): Variables of the Persistence Manager |
(D) Recipe variables |
|
---|---|---|---|---|---|
1 |
The application must maintain device settings. Example: After a power failure, the building control has to have information available about how long a window blind needs to be raised. |
Suitable Preferred use case In this case, you can also use retain variables instead of persistent variables. This is advantageous for variables whose declaration is often changed. |
Suitable Preferred use case Retain variables are an advantage when their declarations are changed often. |
Suitable Advantageous for controllers which do not have any hardware support Special functionalities make this possible, such as double file buffering. |
Possible, but very complicated and therefore not recommended |
2 |
The application must maintain values also after program changes or extensions. |
||||
2a: Rare extensions Example: An application programmer extends the program with a new switch and installs a new light. The building control must still have saved values available until then. |
Suitable Preferred use case |
Suitable |
Suitable |
Possible, but complicated |
|
2b: Unrestricted changes, including deleting or changing the data type of variables The building control is running and is persistent. When an application programmer adds a new functionality to the controller and therefore adds another persistent variable to a function block, the values saved up to that point must be retained. For example, the program in an FB is extended with a variable that controls the automatic switching off of a previously uncontrolled lamp after a certain time. The building control must have the times of all controlled lamps available after the extension. |
Not suitable |
Suitable Data from retain variables are preserved as far as possible after an online change. |
Suitable as far as possible Preferred use case |
Possible if textual, but complicated |
|
2c: The application must maintain values after a download. |
Suitable |
Not suitable |
Suitable |
Suitable |
|
3 |
The application must be able to use different value sets. Example: The operating settings for summer, winter, and holidays must be saved and imported when needed. |
Not suitable |
Not suitable |
Not suitable |
Suitable Preferred use case |
4 |
The application must be able to use settings from another system. It must be possible to transfer settings to another plant using similar variables. |
Not suitable |
Not suitable |
Suitable |
Suitable |
5 |
The application must provide human readable data. The user must be able to read, compare, and edit the data. |
Not suitable |
Not suitable |
Suitable |
Suitable |
Disadvantage: Only possible if the runtime system supports this mechanism and an NVRAM memory or UPS is available. Advantage: Speed; recommended application: 1 and 2a
Disadvantage: In the case of large variable sets (> 10000), long delays during initialization and shutdown are to be expected. Advantage: No special memory is required; value retention exists even in case of changes, extensions, or deletions.
Advantage: Editable remotely, transferable. Disadvantage: Complicated